I'm still against this. You've gone to enough lengths to build things that you essentially don't need to be using BinDeps any more.

This is wrong and harmful for any existing package that declares it provides binaries, to make them newly applicable when they were not before, so could easily be quite breaking.

Sure, but all of BinDeps' questionable behaviors are pretty ingrained and making any changes to them can have nasty consequences (e.g. #277, which still needs to be reverted or worked around in order for master of BinDeps to be releasable for any currently released version of Julia). If 90% of what you want to do at this point is download a file, I don't think it's worth changing this for every existing downstream package.

You've gone to enough lengths to build things that you essentially don't need to be using BinDeps any more.

I definitely do, since the binaries I've built are only for the 5 most common platforms, and anything else has to fall through to the BinDeps-provided build process. I can try to work around it with conditionals, but then when I'm using the built binaries I basically have to reimplement a bunch of the BinDeps machinery for unpacking, checking checksums, and all of that. I essentially have to write my own provides(Binaries, ...) to work around it not being available on one platform.

Currently the best solution I have to get around this pretty crippling limitation is stuff like JuliaMath/FFTW.jl@eb979b7, which hopefully we can agree is the greater of two evils here. Suggestions for that PR are more than welcome.

I don't think it's worth changing this for every existing downstream package.

It seems unlikely that anyone would be actually relying on this not working, so it would likely not be a breaking change, and would in fact be beneficial for other package authors in similar situations.

This would enable binaries that currently aren't enabled. Including potentially ones that are labeled as being Linux compatible but are not.

Again, that's the fault of the package author, not of BinDeps. We shouldn't make it impossible to use binaries on Linux just because some people don't know how to make redistributable binaries.

it's not impossible, there's a workaround that can be applied one package at a time when things are known to work, as opposed to potentially exposing every downstream user of bindeps to a risky behavior change.

What's the workaround then?

This would enable binaries that currently aren't enabled. Including potentially ones that are labeled as being Linux compatible but are not.

I'd like you to provide an example of a registered package that would be negatively impacted, instead of claiming that there may be one. In my grepping through all registered packages I have found only examples where users are already subverting this change at runtime; e.g. our workaround in FFTW.jl as well as LibHealpix and Yeppp. I don't see any other instances of provides(Binaries, ....) that would be run on Linux.

I don't see how unbreaking this behavior can possibly be considered risky behavior; if I had a download() function that worked on OSX and Linux but not Windows, I would not consider it a risk to fix the bug on Windows, worrying that some other user may be relying on the download() function to not work; this is very clearly a case where if user code somehow does depend on this functionality it should be updated.

There will be more people fall into this pitfall and track back to this pull request.
The first time when I find out binary is missing from the list I thought it was the author went to lunch before finishing the line.
Having it may or may not cause problems but will certainly save a lot of debugging time for package developers who use BinDeps for the first time.

Will look into it, at least in public code. Been traveling 2.5 of the past 3 days

I don't think that's a fair analogy as this was left out of the platform dependent defaults list intentionally.

This (and all existing workaround uses of it) are broken and wrong on non-glibc distros. This should be reverted.